NASA USRP - Internship Final Report 


Human Machine Interface Programming and Testing 

Thomas G. Foster 
Kennedy Space Center 
Major: Computer Engineering 
KSC FO Summer Session 
Date: 07/29/2013 


Kennedy Space Center 


29 July 2013 





NASA USRP - Internship Final Report 


Final Report Abstract: 

Human Machine Interface (HMI) Programming and Testing is about creating graphical displays to 
mimic mission critical ground control systems in order to provide NASA engineers with the 
ability to monitor the health management of these systems in real time. The Health Management 
System (HMS) is an online interactive human machine interface system that monitors all Kennedy 
Ground Control Subsystem (KGCS) hardware in the field. The Health Management System is 
essential to NASA engineers because it allows remote control and monitoring of the health 
management systems of all the Programmable Logic Controllers (PLC) and associated field 
devices. KGCS will have equipment installed at the launch pad, Vehicle Assembly Building, 

Mobile Launcher, as well as the Multi-Purpose Processing Facility. I am designing graphical 
displays to monitor and control new modules that will be integrated into the HMS. The design of 
the display screen will closely mimic the appearance and functionality of the actual modules. 

There are many different field devices used to monitor health management and each device has its 
own unique set of health management related data, therefore each display must also have its own 
unique way to display this data. Once the displays are created, the RSLogix5000 application is 
used to write software that maps all the required data read from the hardware to the graphical 
display. Once this data is mapped to its corresponding display item, the graphical display and 
hardware device will be connected through the same network in order to test all possible scenarios 
and types of data the graphical display was designed to receive. Test Procedures will be written to 
thoroughly test out the displays and ensure that they are working correctly before being deployed 
to the field. Additionally, the Kennedy Ground Controls Subsystem’s user manual will be updated 
to explain to the NASA engineers how to use the new module displays. 

I. Introduction 

The Kennedy Ground Control Subsystem (KGCS) is a Programmable Logic 
Controller (PLC) based industrial control system tasked with the responsibility of developing 
command and control capabilities for specialized equipment in support of the Ground Systems 
Development Operations program (GSDO). The GSDO Program’s mission is to prepare the 
Kennedy Space Center (KSC) to process and launch the next generation of rockets and 
spacecraft in support of NASA’s exploration objectives by developing the necessary ground 
systems, infrastructure and operational approaches. To support this mission, KGCS will need to 
have equipment installed at the launch pad, Vehicle Assembly Building, Mobile launcher, and 
the Multi-Purpose Processing Facility. 

In addition to the command and control function, the KGCS also provides an advisory 
system for its equipment. The KGCS Health Management System (HMS) is a collection of 
Human Machine Interfaces (HMI), or displays, that allow KGCS engineers to monitor the health 
and status of all KGCS equipment deployed in the field from a centralized location. The HMS 
increases the KGCS engineer’s operational awareness capabilities by providing real time 
feedback on the health and status of all equipment used in KGCS. This knowledge becomes 
especially important during vehicle launch operations to aid in troubleshooting and anomaly 
detection. In order to ensure that the data displayed by these HMIs is accurate, each HMI must 
be thoroughly tested and certified for use in the field before it can be deployed. Once deployed to 
the field, all KGCS equipment implementing that display must be retested to find any 
inconsistencies in the system. 

The process involved in creating these HMIs starts with the identification of a new 
hardware device, or module, to be used in the field. For this project, HMIs were developed for 
the following hardware devices: 


2 


Kennedy Space Center 


29 July 2013 



NASA USRP - Internship Final Report 


• Redundant Ethemet/IP to Foundation Field Bus (EN2FFR) Linking Device Module. 

• DeviceNet Module. 

• 16 point Normally Open Individually Isolated Relay Contact Output Module (OW16I). 

These devices are scheduled to be installed by KGCS as part of the Multi-Purpose Processing 
Facility installation. The HMls for these devices were created using the FactoryTalk View Studio 
application and were designed to closely mimic the appearance and functionality of the actual 
hardware. Once the graphical display was created, health and status routines were created to 
populate the data required by the HMIs with values from the hardware. These health and status 
routines are created using a program called RSLogix5000 and are installed on the actual PLC 
processor. When these routines execute, they gather the required information into constructs 
referred to as “tags”. These tags are then communicated to the HMI Server via an EtherNet/IP 
network connection where they are mapped to their appropriate spot on the graphical display. 
After communication of all system components is established, thorough testing is performed to 
ensure the HMI is performing all its required design specifications. The final step of this process 
is to draft user manual and test procedure documentation that accounts for all possible scenarios 
that NASA engineers may encounter while using this device in the field. 

II. Details 

The first step to creating a new HMI is to understand the complete functionality of that 
device. For instance, does the device have LED status indicators and if so what are all the 
possible conditions and states of these indicators. Also, if the device has some form of 
alphanumeric display it is important to know every possible condition this screen can display and 
when it displays them. This information is not always made readily available, this part of the 
design phase often becomes tedious because the designer must search through various user 
manuals and documentation to find any relatable information that can be used. It often becomes 
necessary to call the device manufacturer and speak with the interoperability engineers for that 
specific device in order to discover specialized details about its operability. Once all pertinent 
information about the device is gathered a design is pieced together. 

After the design of the graphical display is finished the hardware device is placed in a 
PLC chassis where is it connected via backplane to communication modules and or a PLC. At 
this point a network is established through Ethemet/IP or Control Net to connect RSLogix5000 
and FactoryTalk View software applications to PLC chassis where the hardware device is 
located. Once all the system components are communicating properly it becomes time to start the 
system test procedures. The test procedures are not just important to ensure the operability of the 
hardware but also to help develop how the graphical display will be designed. Through the use of 
RSLogix5000 the user can simulate specific conditions by writing software to make the 
hardware device think some error has occurred or likewise some expected action has taken place. 
Doing this is very useful because it allows us to see exactly how the device responds to these 
different conditions. It is important to test every possible condition that would make the device 
act abnormally as well as normally. Once it is realized how the device will react to any possible 
condition that may influence its operability and or physical characteristics the graphical display 
can be likewise programmed to mimic the exact functionality of the device. By simulating the 
same conditions in FactoryTalk View via RSLogix5000 the graphical display is designed to 
change states just as the hardware device would change in response to the simulated condition. 
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The EN2FF linking device provides a gateway between Ethemet/IP and a single segment 
Foundation Fieldbus HI layer. It can support up to 16 devices and is configurable through the 
RSLogix5000 software application. Multiple levels of media redundancy are supported, 
including ring, split, and redundant trunk, plus options for H 1 media, redundant linking devices, 
redundant controllers, and ControlNet. In order to develop the HM1 for the EN2FFR it was first 
connected to a power bus then linked to the PLC network via Ethemet/IP and ControlNet 
modules. The EN2FFR was then physically linked to temperature sensors with manipulation 
capabilities supplied by decade resistors. Test procedures were then introduced to assess the 
boundaries of the health management capabilities of the EN2FFR. The reason being to realize 
what types of health management intelligence could be extracted from the module. After the 
graphical design was complete, it was linked with the EN2FFR hardware module through 
FactoryTalk View and RSLogix5000 software applications and tested to ensure that when a 
health management oriented condition changed on the hardware module it likewise changed the 
same characteristics on the EN2FFR graphical display. While developing health and status 
routines for this device I was not able to retrieve certain health information important to the 
health management of the device. After contacting the interoperability engineer for the EN2FFR 
it was realized that it was not possible to compel this certain health data out of the EN2FFR. This 
is often the case when dealing with complex hardware systems and served as a good learning aid 
in uncovering the boundaries of hardware systems. The following diagrams are screenshots of 
the EN2FFR display used when creating the user manual for this device. 
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Amperage in millivolts 
measured on Bus A 


DC Voltage measured on 
Bus A 


DC Voltage measured on 
Bus B 


HI node address of master 
(default 16). 


Communication enabled 
indication for HI bus A & B, 
Possible states are True or 
False. 
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Temperature 


FF Master Node 


Bus A Enabled: 


Bus B Enabled: 


Bus A Tripped: 


Bus B Tripped: 


Bus A Term: 


Bus B Term: 


HI Bus A and/or Bus B has 
tripped indicating that there 
was an over-current on 
either port. Possible states 
are True or False. 


Amperage in millivolts 
measured on Bus B 

U Internal temperature of EN2FFR 
measured in degrees Celsius. 
Operating temperatures should 
be within 0 - 50 C range. 


HI Bus A and/or Bus B has 
tripped indicating that there 
was an over-current on either 
port. Possible states are True or 
False. 



Tag Name given in RSLogix5000 to currently 
displayed field device 


EH TMT162 F900BC0 


ConfigRunnmg 


Print 


FF Field Device 


Number designation for field device 
currently displayed. Possible values are 0 
through 15. 


Node of currently displayed 
field device. Nodes are 
assigned by the EN2FFR. 


Status of currently displayed 
field device. Possible states: 
NotConnected - device cannot 
be seen. 

Online - device online but not 
configured. 

ConfigRunning - device is 
configured and running. 


The functionality of these displays included the design and programming of buttons to allow the 
user to navigate from the EN2FFR home screen to all subsequent EN2FFR screens to view any 
associated health or status information. 

The DeviceNet Network provides open, device-level control and information networking 
for simple industrial devices. It supports communication between sensors and actuators and 
higher-level devices such as programmable controllers and computers. With power and signal in 
a single cable, it offers simple and cost-effective wiring options. The DeviceNet module was first 
placed into a Remote Input /Output chassis (RIO) to provide communication capabilities with the 
PLC network. It was then physically linked to two magnetic Halifax switches in order to test 
communication and control of devices on the DeviceNet network. While installing the hardware 
for the DeviceNet module it was realized that there was a communications error between the 
module and magnetic switches it was linked to. By troubleshooting the power supplies it was 
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discovered that the DeviceNet power tap bus had a blown fuse. This was discovered by using a 
digital multi-meter to check for voltage on the load side of the power tap bus, after detecting no 
voltage was being delivered from the bus a check on all fuses associated with power tap bus lead 
to the discovery of a blown fuse. Once this fuse was replaced the system worked perfectly and 
testing was resumed. The health management testing procedures were virtually the same as the 
EN2FFR with the intent of figuring out all possible device health information that could be 
extracted from the DeviceNet module. One major difference discovered after closer review of the 
user manual for this module was that more detailed health information for this device was 
accessible through Common Industrial Protocol (CIP) messaging. By developing the CIP 
messages through ladder logic programming language via the RSLogix5000 application these 
messages where sent to the DeviceNet module requesting specific health information. Once this 
information was retrieved it was stored in a program tag where it could be mapped to its 
appropriate location on the DeviceNet module. The following diagrams are screenshots of the 
DeviceNet display used when creating the user manual for this device. 



1 . ) The DeviceNet status display notifies the user: 

• What node address the DeviceNet module is currently on. 

o A#00, A#01...A#63. 

• The Current status of the module. 

o Idle, Run, Network Disabled, Fault, Test... etc. 

2. ) Halt Scanner operation allows user to halt all operations on DeviceNet module. 

• If Halt Scanner bit is set, user must physically cycle power to restart module. 

3. ) Reset operation resets all bits to 0 to resume operation. 

4. ) The following table outlines the indicator condition with its corresponding status and 
explains what each condition means. There are three status indicators on the DeviceNet 
Module: 
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• Module/Network (MOD/NET) Status Indicator - This bi-color 
(green/red) status indicator provides device and communication 
status. 

• I/O Status Indicator - This bi-color (green/red) status indicator 
indicates the status of the DeviceNet scanner module’s I/O scanning 
state. 

• OK Status Indicator - This bi-color (green/red) status indicator 
indicates whether the device has power and is operating properly. 


Indicator 

State 

Description 

Module/ 

Network 

(MOD/NET) 

Off 

Device is not powered/not online. 

Green 

Device is operating in a normal condition and is 
online with connections established. 

Flashing Green 
(Not displayed on HMI) 

Device is operational AND online and not 
connected or device online and device needs 
commissioning. The device is operating in a normal 
condition and is online with no connections 
established. 

Flashing Red 

Minor fault and/or connection time-out - 
recoverable fault and/or one or more I/O 
connections are in the timed-out state. 

Red 

(Not displayed on HMI) 

Critical fault or critical link failure - device has an 
unrecoverable fault and may need to be replaced. 

I/O 

Off 

Scanner is not online. Check network power 

Flashing Green 

Scanner is in RUN mode, outputs are under 
control, and inputs are being consumed. 

Green 

Scanner is in IDLE mode, outputs are not under 
control, and inputs are being consumed. 

OK 

Off 

No power applied to device. Apply chassis power. 
Verify module is completely inserted into chassis 
and backplane. 

Flashing Green 
(Not displayed on HMI) 

The device is operating correctly; however, no 
controller is controlling it. Verify that the 1756-DNB 
scanner module is properly configured in the 
controller’s I/O configuration 

Green 

Device is operating normally. The 1756-DNB 
scanner module has at least one connection to it 
from a controller. 

Red 

Device has an unrecoverable fault; repair or 
replace it, or Device is in self-test during power-up. 


The functionality of the DeviceNet display included the design and programming of multiple 
multistate indicators to bring visual significance to the LED indicators. The data retrieved from 
CIP messaging was mapped to the Fault Code Message portion of the display to notify the user if 
any internal errors occurred in the module and if so what are the courses of action to correct 
those errors. 
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The OW16I Relay Contact Output module is an internal mechanical device with a 
normally open 16 point contact. The OW16I was connected to the PLC network utilizing the 
same configuration as DeviceNet. For testing procedures it was not needed to connect the 
OW16I to any external devices because all health associated data from the OW16I was 
accessible through CIP messaging. Because the DeviceNet module and OW16I module were 
both manufactured by Allen Bradley the CIP messaging instructions used for the DeviceNet 
module were reusable for the OW16I module. The OW16I has 16 points of contact therefore a 
visibility function was coded into the design to allow the user to see which contacts were active 
at any given time. Also, a multistate visibility function was used for the “OK” module status 
indicator to notify the user if the modules status was good or poor. The following diagrams are 
screenshots of the OW 1 61 display used when creating the user manual for this device. 



Module 

Status 

Indication 


By viewing the display the user can realize which output contacts are active and that the device 
status is currently good. The data retrieved from CIP messaging was mapped to the Fault Code 
Message portion of the display to notify the user if any internal errors occurred in the module 
and if so what are the courses of action to correct those errors. 

Once all testing and design procedures have been completed a user manual and test 
procedure for each hardware device has to be documented to address all possibilities NASA 
engineers may encounter while using this device in the field. The user manual must be very 
thorough detailing what the hardware device does and what every physical characteristic of the 
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device pertains to internally. If any piece of the device can visually change states, the possible 
state changes and what those changes mean must also be explained. All information is organized 
professionally through graphical representations and detailed explanations. After the user manual 
is finished test procedures for every graphical display associated with the hardware device must 
be documented. The test procedures provide a system of checks that allow the user to ensure that 
the changes viewed on the hardware device match the corresponding changes viewed on the 
display. All data sent from the system and received from field devices that can be viewed on the 
graphical displays must also be annotated. 

III. Conclusion 

This internship has been an incredible learning experience, especially at the system level. 
During this project I have designed and built graphical displays using software and interfaced 
these graphical displays with the actual hardware they are designed to monitor and control 
through the development of code in multiple software environments. Then tested all possible 
scenarios on the hardware to make sure the graphical design and hardware operations were 
identical. The system level experience I have gained is invaluable to my understanding of how an 
entire system is designed, tested and ultimately works together to perform complex operations. 
This experience will without a doubt prove useful in upcoming senor project and future job 
positions. 
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